fix(typescript): lift the per-call budget cap, exit 124 on timeout, guard deep nesting - #2835

Requested by Михайло · project thread

What changed

The TypeScript (ZapCode) runtime had the same gaps that a downstream review found in the Python runtime (#2831, #2832, #2833), plus one that crashes the host process:

• Process abort on deeply nested source (TM-TS-024). ZapCode 1.5.1's parse/lower/compile steps recurse with no depth guard. About 6 KB of nesting, such as [[[...]]] or 1+1+..., overflowed the native stack and aborted the whole host (SIGABRT) in release builds. On a 2 MB debug thread it took only about 100 levels. Bashkit now guards this in two layers:
  • A conservative nesting estimate (typescript_nesting.rs) rejects source estimated deeper than 1000 levels with ts: source is too deeply nested (exit 1).
  • Parse and compile run on a dedicated thread with a 128 MiB stack. This is reserved, not committed. The smallest stack that passed every nesting shape at the cap in a debug build was 32 MiB, so this is a 4x margin. wasm32 runs inline, and the cap still applies there.
• Call cap. Each ts call reserved max_allocations (1M) budget units up front, so a script hit the default 100M budget after about 95 calls. Each call is now charged a flat 4096 units plus the time the VM actually ran.
• Timeouts. A ZapCode time-limit hit now exits 124 with ts: execution timed out after Ns, matching python3 and coreutils timeout. The exit code comes from ZapCode's dedicated error variant, so a script's own throw cannot fake it.

Why

Agents run ts many times per script. A crafted few KB of source must never take down a multi-tenant host, and callers need to tell a limit hit apart from a script error.

Before / After

Tests:

• deeply_nested_source_fails_cleanly
• deep_nesting_at_the_limit_does_not_overflow (18 AST shapes at the deepest accepted size)
• deep_nesting_past_the_limit_is_rejected
• many_small_invocations_fit_in_one_script
• time_limit_exits_124
• thrown_error_is_not_a_limit
• Scanner unit tests covering the shapes that must be counted and the ordinary programs that must stay small.

Risk

• Medium.
• A single statement with more than about 1000 tokens and no , or ; (for example, a giant string concatenation) is now rejected. Ordinary programs, long arrays and long statement lists score well under 100.
• Each ts call now spawns one thread, which costs tens of microseconds.
• Upstream fix wanted: a depth guard in zapcode-core.

Checklist

• Tests added or updated
• Backward compatibility considered

Generated by Claude Code

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}